If you're passionate about Proxmox and virtualization, you've probably been tempted to build a ZFS pool using consumer-grade ("non-enterprise") SSDs. The logic seems airtight: ZFS offers data integrity, snapshots, and compression. The reality, however, tends to be a hard hit: in under a year, your SSDs can be gone for good.

I lived through this myself: I set up a ZFS pool with two 1TB Patriot SSDs for my virtual machines in Proxmox, and almost exactly one year later, one of them died irreversibly. Why does this happen?

The technical problem: constant writes and "Write Amplification"

The problem isn't that ZFS is "bad" — it's that it was designed for servers. ZFS is a copy-on-write filesystem (Copy-on-Write or CoW). This means that, instead of overwriting data blocks, it writes new blocks and then updates the pointers.

On top of that, three critical factors come into play when using consumer-grade SSDs:

  1. Write Amplification: Because of how SSDs work internally, writing is a complex process. ZFS performs many small, frequent write operations (logs, metadata, VM state updates). This forces the SSD controller into constant erase-and-write cycles, wearing down the flash memory cells at a punishing rate.

  2. Synchronization (ZFS Intent Log – ZIL): ZFS is extremely strict about data integrity, which forces constant synchronous writes. Enterprise SSDs have capacitors (PLP – Power Loss Protection) that handle this comfortably. Consumer SSDs don't, which pushes the wear level far beyond what the manufacturer ever predicted for home use.

  3. Proxmox logs and telemetry: By default, Proxmox constantly writes logs to disk. On a ZFS system, these small state changes multiply, turning your SSD into a relentless writing machine.

How to protect your SSDs in Proxmox?

If you're already using consumer SSDs, or don't have the budget for enterprise drives (like Intel DC or Samsung's PM/SM series), the goal is to drastically reduce unnecessary writes.

1. Reduce system logs

Proxmox writes a lot of information to the system journal. You can configure journald so logs live only in RAM instead of constantly hitting the SSD:

Edit the configuration file:

nano /etc/systemd/journald.conf

Adjust the following parameters:

MaxLevelStore=warning
MaxLevelSyslog=warning
Storage=volatile
ForwardToSyslog=no

Save and restart the service:

systemctl restart systemd-journald.service.

2. Set up log2ram

The best way to avoid disk writes is to use Log2Ram. This creates a mount point in RAM memory where logs are written, syncing them to disk only periodically.

Install it like this:

echo "deb [signed-by=/usr/share/keyrings/azlux-archive-keyring.gpg] http://packages.azlux.fr/debian/ bookworm main" | tee /etc/apt/sources.list.d/azlux.list
wget -O /usr/share/keyrings/azlux-archive-keyring.gpg https://azlux.fr/repo.gpg
apt update && apt install log2ram -y
reboot

Check its status with:

systemctl status log2ram.

3. Disable unnecessary services (HA)

If you're not running a high-availability cluster, the HA (High Availability) monitoring services write to disk constantly. Disable them:

systemctl stop pve-ha-lrm.service
systemctl disable pve-ha-lrm.service
systemctl stop pve-ha-crm.service
systemctl disable pve-ha-crm.service

Monitor your drives' wear level

Don't wait for the disk to fail. Use smartmontools to check how much life your SSD has left before it's too late:

apt-get install smartmontools
lsblk
# Replace /dev/nvme0n1 with your drive
smartctl -a /dev/nvme0n1

Look for the "Percentage Used" or "Media and Data Integrity Errors" value in the command output.

Conclusion

ZFS is a wonderful technology, but if you're using consumer hardware, prevention is mandatory. Reducing log activity through RAM and disabling unnecessary services won't make your €50 SSD behave like a €500 one, but it can be the difference between a disk lasting 1 year or 3.